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ABSTRACT 


This thesis addresses a known problem in Carrier Aviation. The problem is the 
constant duplication of effort writing the carrier airplan. This problem is common to all 
airwings and results in late airplan publish times which reduce the combat effectiveness of 
the battlegroup. The analysis of the airplan is accomplished through the establishment of 
a database of carrier airplans. The database interacts with a spreadsheet designed to help 
Strike Operations aboard the carrier streamline the process of writing the airplan. 

The prototype model developed accepts inputs from the Assistant Strike Operations 
Officer. The model searches the database for airplans that conform to his inputs and 
provides candidate airplans for review. Once an airplan is selected, an airplan template, in 
spreadsheet format, can be altered to meet any required changes. Once changed to meet 
specific tasking the final product can be saved. After a period of operations the database 
search file can be updated to mold the database to a specific ship and airwing’s standard 


operating routine. 
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THESIS DISCLAIMER 


The reader is cautioned that the computer program developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the program is free of computational and logic 
errors, it cannot be considered validated. Any application of this program without 


additional verification is at the risk of the user. 
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I. INTRODUCTION 


A. PROJECT BACKGROUND 

This Masters Thesis is written in partial response to a Chief of Naval Operations 
(OP-73) Tactics Development and Evaluation (TAC D & E) proposal. The proposal 
addresses a known problem within the Aircraft Carrier Aviation community of the United 
States Navy. The problem is inefficiency in the daily airplan production process. In 
addition to the duplication of effort in airplan production, late publish times for the 
airplan have repercussions seen throughout the ship, airwing and accompanying 
battlegroup. In many cases the individual warfare commanders, such as the air warfare 
or anti-submarine warfare commander, are not embarked on the aircraft carrier. They 
are dependent on the airplan to outline the aircraft assets they will have at their disposal. 
The overall effect of the airplan’s late promulgation is lost productivity and reduced 
combat effectiveness for the battlegroup. 

The carrier airplan is described in detail in following sections for the reader 
unfamiliar with carrier operations. The most basic explanation is that the airplan is the 
single approved flight schedule for the whole carrier airwing. Any flights originating 
and/or terminating aboard the aircraft carrier are scheduled via the airplan. The airplan 
directly or indirectly affects the actions of every person aboard the aircraft carrier and, 


ii Most cases, every ship in the accompanying battlegroup. 





The airplan does not include actual names of aircrew flying each sortie, that is the 


responsibility of squadron operations departments. The airplan provides structure for 
each squadron’s flight schedule. Publishing the airplan late forces squadron operations 
departments to hold production of their flight schedules. This forces similar reduction 
in combat effectiveness within the airwing. 

The TAC D & E proposal addresses three problem areas. The first area is analysis 
of the airplan and the production process. This portion is to include factors which have 
direct and indirect affects on the daily airplan. Second, the proposal seeks to clarify 
which of these factors are quantifiable, if any. And, finally, the project should attempt 
to automate the production process. The proposal suggests a prototype model to be 
experimented with during an aircraft carrier workup phase. That model is to be followed 


by a full-scale working model. 


B. CARRIER AVIATION INTRODUCTION 

Aircraft carrier aviation consists of several facets of the Navy working together. 
An understanding of what the people and machines do and how they interact must be 
established, along with some vocabulary specific to carrier aviation. This is necessary 


to comprehend the analysis and recommendations to follow. 


1. Vocabulary 
@ Airplan: The single approved flight schedule for the embarked airwing. 


@ Strike Operations: The office on the aircraft carrier that composes the daily 
airplan. The ship’s focal point for all airplan information. 


@ Launch: Take off from aircraft carrier. 











@ Recover: Land on the aircraft carrier. 

@ Recovery: Actual landing of a group aircraft. 

@ Cycle: Period between successive launches, normally between one and two hours. 
@ Event: One or more aircraft launching with the same callsign. 

@ Flight: A group of two or more aircraft. 

© Turnaround Time: Time needed to prepare a recovering aircraft for later launch. 


@ Deck: Refers to the flight deck of the aircraft carrier and its capability to 
accomplish flight operations 


@ PIM: Projected Intended Movement. Course and speed the si.:p must make over 
a determined period. 


@ Trap: Landing aboard the ship. 


© Sortie: A mission accomplished by a single aircraft that launches and recovers 
aboard the carrier. 


® Night Sortie: A sortie that recovers at night. 
2. Aircraft Carrier 

The aircraft carrier is organized into several departments that accomplish 
various tasks. Each of the following departments place constraints on the ability of the 
aircraft carrier to conduct flight operations. The Operations Department is responsible 
for the airplan. The actual production of the airplan is accomplished by Strike 
Operations (STKOPS) which is part of the Operations Department. The Operations 
Department gathers inputs from other departments aboard the ship, the warfare 


commanders, and other ships in the battlegroup. These inputs, along with standing 








operating orders, or battlegroup commander requirements, form the structure for the next 
day’s airplan. 

There are two basic operating situations for the carrier battlegroup; 
independent battlegroup operations and combined command support. During independent 
battlegroup operations, the battlegroup commander, airwing commander and the carrier 
commanding officer set the tempo of operations for the carrier and the battlegroup. The 
battlegroup will accomplish training to maintain full combat readiness. For the airwing, 
these training requirements are outlined in the COMNAVAIRPAC/COMNAVAIRLANT 
Joint Training Instruction [Ref 1]. In the combined command support role, the carrier 
battlegroup commander is subordinate to a fleet or combined commander. In this case, 
the tempo of operations is set by the combined commander, and is promulgated through 
an Air Tasking Order (ATO). In either case, the Operations Department formulates the 
Structure for the next day’s airplan. The operating pace of the ship and airwing is 
reduced to four basic variables: 

@ Number of day cycles, 

@ Number of night cycles, 

© Total number of sorties, 

@ Time flight operations will commence and secure. 

It is then the task of the Assistant Strike Operations Officer (ASTKE) to meet 
all standing operating orders, ship imposed constraints, and any other known operating 
limitations while composing the next day’s airplan. These constraints and limitations 


come from many areas. Air Operations (AIROPS), another division of the Operations 





Department, functions much like civilian aviation air traffic controllers. AITROPS 
controls the airspace within fifty nautical miles of the carrier. They impose a maximum 
number of sorties allowed for any given recovery. This applies mainly at night. 
Duties also include: 

@ Track all airborne airwing assets within fifty miles of the carrier. 

@ Maintain location data on all other airborne tracks within fifty miles of the carrier. 

@ Maintain status board of all airwing assets. 

@ Control airborne tanking procedures. 

@ Maintain flight following radar in congested areas. 

@ Maintain status of aircraft in overhead pattern. 

@ Provide alternate landing field information to aircraft in need. 
AIROPS could become overwhelmed if too many aircraft are airborne. In this way, 
AIROPS constrains the airplan. Too many airwing sorties airborne, or a combination 
of that and other limiting factors can severely restrict the airplan options. 

Other departments aboard the ship also impact the airplan. The flight deck 
can only support a certain number of sorties for any given cycle, dependent on many 
factors. The Navigator determines the course and speed (PIM) the ship must make to 
meet scheduled commitments. Since flight operations can adversely affect the ability of 
the ship to make PIM, this can constrain the airplan. Other constraints are planned 
evolutions where flight operations are impossible, such as underway replenishment. The 


ship’s non-aviation training requirements must also be considered. 








ASTKE must organize all the inputs from the Operations Department to 
compose a viable airplan. What has evolved is a system of priorities. Each major 
contributor’s input to the airplan is prioritized, and the requirements are met within 
coasts Once each of these items is considered the airplan is written. The priorities 
are: 

@ Air Tasking Order or Battlegroup Commander Intentions. 
® Warfare Commanders’ Intentions. 

@ Ship’s Training. 

@ Airwing Training. 

The approval process subjects the airplan to careful scrutiny. The proposed 
airplan is initially checked by ASTKE. The next step is the Strike Operations Officer. 
He is most concerned with ships training and ensuring there is a sufficient number of 
certain missions for the ship to maintain special qualifications. Next, the airplan must 
win the approval of the Air Operations Officer. He ensures the airplan can be flown 
safely. His considerations include the number of aircraft airborne at any given time and 
the ability of the flight deck to ready aircraft for subsequent launches. The approving 
Signature is the carrier Operations Officer. His focus is ensuring an overall flyable 
airplan and that all standing orders and tasking have been met. A diagram of the input 


and approval process can be seen in Figure 1. 
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Figure 1 Airplan Approval Process 














3. The Airwing 


The aircraft carrier notional airwing consists of a mixture of multi-mission 

aircraft. Table 1 shows the notional airwing assets. 

@ Two squadrons of F-14A, Air Interceptors. 

®@ Two squadrons of F/A-18D, Light Attack and Fighters. 

@ One Squadron of A-6E, Medium Attack and Tankers. 

@ One squadron of EA-6B, Electronic Countermeasures. 

@ One squadron of S-3B, Anti-surface and Subsurface, Tankers. 

@ One squadron of E-2C, Early Warning. 

@ One squadron of helicopters H-3 or SH-60F, Anti-submarine and Logistics. 
The helicopters are not included in the analysis portion. Helicopter launches and 
recoveries do not have a significant impact on the airplan. The model proposed in 
Chapter IV accommodates all other assets common to the aircraft carrier including 
Carrier Onboard Delivery by fixed wing assets. The analysis is directed strictly at 
organic fixed wing assets. 

The flight qualification of squadron pilots is an important factor in the daily 
airplan production. Safety requirements imposed by the Landing Signal Officer Naval 
Air Training Operations Program Standardization (LSO NATOPS) dictate that each 
squadron pilot fly a minimum of one night landing within a seven day period to remain 
eligible to fly at night from the aircraft carrier. If this minimum is not met, a series of 
flights must be performed to requalify a squadron pilot to become eligible to land at 


night. Responsibility for pilot night currency lies with squadron Operations Departments. 


TABLE 1 NOTIONAL AIRWING 


SQUADRON | AIRCRAFT | NUMBER NUMBER OF 
TYPE TYPE SQN PILOTS 
F14A 


1 
VE [risa | to +1 
[VFA | F/A-18p 


VFA F/AI8D | 11 +/-1 


VA A-6E 10 ATTACK | 7 BOMBER 
3 TANKER | 2 TANKER 





They must manage night sorties/landings to maximize the number of night current pilots. 
Maintaining pilot night currency also places constraints on the carrier planning staff. The 
ship must, as a minimum, plan for 120 night sorties per seven day period. 

Squadron maintenance departments must perform daily maintenance on 
aircraft for them to be mission-capable for subsequent flights. Aircraft turnaround time 


is a major limitation on the size of the daily airplan. 


C. CARRIER AIRPLAN 
The airplan can be described as a two dimensional array. Each element of the 


array is a complex entity that represents what a squadron is tasked to accomplish during 


a specific period of the day. The periods, as defined earlier, are airplan cycles. The 
entities in each cell of the array are events, or flights of sorties. 

Tasking often will determine the cycle time, which can vary throughout the day, 
but is usually between one and two hours. Cycle length has a direct impact on 
production of the daily airplan. The following list gives the potential impact a change 
in cycle time can have. 

@ Change necessary fuel loads for each aircraft type. 
@ Change airborne tanker requirements. 


@ Type and number of aircraft available for current and future missions. This is due 
to turnaround times. 


@ Combat Packages. 

@ Search area coverage and on-station time. 

@ PIM due to time into the wind for launch and recoveries. 

@ Amount of tactical training an event can accomplish due to fuel constraints. 
One major problem with cycle time is that there is not a single length which best satisfies 
each squadron’s operations and training requirements. 

A callsign is assigned to each squadron event. It consists of a number, a letter, and 
another number. The first number determines launch cycle. The letter is the squadron 
identifier, A-H for organic airwing assets and X for logistics assets not actually part of 
the airwing. The final digit specifies events within each squadron. Figure 2 is a typical 
carrier airplan. Some information obtained from the airplan is listed below: 


@ Event callsign, 


10 
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Pigure 2 Carrier Airplan 
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@ Number of aircraft in an event. 


@ Launch time. . 
@ Recovery time. ° 
@ Fuel load if non-standard. 

@ Mission areas. 

@ Tanking requirements for each sortie. 

@ Combat Package/Ordnance loadout. 

@ Notes particular to each flight. 

@ Alert status. 


@ Emergency information. 


D. GOAL 
The goal of this thesis is to address the first two areas of the proposal and suggest 
a number of models for possible development by other thesis students from the following 
departments, 
@ Operations Research. 
® Computer Science. 
®@ Information Systems. 


A prototype of one of the suggested models is included for evaluation. 


E. APPROACH 
The approach taken was to organize a number of airplans, then analyze aspects of : 


the airplans to determine the factors that limit the daily production of the airplan. An < 


12 


attempt is made to quantify those aspects that have the greatest influence on the 
difference between a feasible and unfeasible airplan. While it is obvious there could be 
numerous sortie mixtures on any given airplan, the goal is to characterize the typical 


airplan as closely as possible. 


F. LIMITATIONS 

As stated above, there are numerous possible sortie mixtures for any given set of 
airplan constraints. That number expands rapidly when all possible mission types are 
taken into consideration. The sheer size of the problem, and knowledge of the process, 
forces constraints from the outset. 

These constraints are complexity, compatibility and cost limitations. First, the 
model should be easy to use for someone with basic computer knowledge. The model 
should also be small enough to run in a reasonable amount of time on a relatively small 
computer (386SX based IBM or compatible computer with one or two megabytes of 
random access memory). This is the class of computer normally available in the Strike 
Operations Office of an aircraft carrier. Finally, the software used for the prototype 
model should be multi-purpose, off the shelf, commercially available programs 
preferably already used on the carrier. If the end user has to purchase software, it was 


decided that the cost should be kept under $500.00. 


13 


Hf. DATABASE ESTABLISHMENT 


A. INTRODUCTION 

This chapter explores the structure of a database that will benefit mission planners 
in STKOPS. The carrier airplan is a dynamic document with inputs coming from 
numerous different areas. The structure of the database designed for storage of airplans 
is dependent on the intended use. A useable database structure was sought with two 
goals in mind, analysis of the airplan and airplan production. For airplan analysis, the 
format must allow quick calculations, sorting across numerous fields and convenient 
storage of statistics. For airplan production, the primary consideration was table look 
up, or query ability. The production phase will be addressed with the model 


recommendations. 


B. DATABASE TERMINOLOGY 

Before addressing the actual database structure, some terminology must be 
explained. A database can be thought of as a list of items with traits describing them. 
These items are called entities and the traits attributes. In other words, an entity is some 
object that occurs in nature. The object is made unique by assigning its attributes certain 
values. For example, assume a database is constructed of pilots in a squadron. The 


obvious entity would be the PILOT. The PILOT entity would have attributes such as, 


first, middle, and last names, department, rank, etc. Each of these attributes is given 








values in the database. Another way of picturing entities and attributes is to think of 
entities as rows of a table and attributes as columns. Figure 3 is a schematic of the 
PILOT entity. [Ref 2] 

The most important factor in the construction of databases is the key. A key is an 
attribute or group of attributes that make an entity or row unique. In the PILOT 
example, a key is the Social Security number. The key uniquely determines each pilot 
in the squadron. 

The power of well structured databases is the ability to quickly search through and 
find information about specific entities or groups of entities, and the ability to sort all 
files depending on attribute values. These processes are called queries and sorts. The 
ability to ask the database to produce all records that have a certain value for a specific 
attribute or to sort the database according to a certain attribute value provides the user 


quick access to significant amouiits of information. 


C. DATABASE SCHEMA 

A tabular, or flat file, database structure was selected for use in this project. This 
was done with the end user in mind. The simple structure accomplishes the analysis and 
production goals listed earlier and should be easily understood by most users. The 
structure allows for quick sorting and queries without the complexity of an Object 
Oriented or Entity/Relationship database model. It also loosely follows the message 


format used for promulgating the airplan throughout the battlegroup after production. 
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ADDRESS 


PILOT 


Fro] wn vane Sn [ex] aoonese oePTRane] GOAL 


ATTRIBUTE VALUES 

FNAME -- CHARACTER (10) 

MINIT -- CHARACTER (3) 

LNAME -- CHARACTER (15) 

SSN -- NUMBER OF FORM #+HHi-HHH 
SEX -- CHARACTER (1) 

ADDRESS -- CHARACTER (25) 
DEPTARTMENT -- CHARACTER (15) 
RANK -- CHARACTER (5) 


MISSION QUALIFICATION -- CHARACTER (5) 


Figure 3 Pilot Entity 
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1. The EVENT Entity 
Referring to the airplan description, the basic element of the airplan is the 
sortie. Each sortie is an individual aircraft with a specific mission. The entity used for 
the basic record of the proposed database however, is the EVENT. Analysis determined 
that a majority of sorties launched were part of a flight, making up an event. The 
selection of the EVENT as the basic entity in the database eliminated many duplicate 
values, reduced the size of each file in the database, and eliminated the necessity of an 
additional attribute. The selection of the EVENT entity also conforms to the prototype 

model description in Chapter IV. 
The EVENT entity, seen in Figure 4, is composed of number of attributes. 
The values for each attribute are also listed in Figure 4. Since the airplan data is stored 
in several different files, the uniqueness of each EVENT entity is important only in 
some respects. This problem is addressed in the discussion of the file types. Suffice to 
say, if individual flights are studied, where uniqueness is required, a DATE attribute 
can be added to achieve uniqueness. The addition of a DATE field is a simple extension 
of the current structure. In this case, the key for these entities is the combination of the 


DATE and CALLSIGN attributes. 


2. AIRPLAN Files 
The base file or storage file is the AIRPLAN file. Each of these files 


contains a list of EVENT entities that make up a single daily airplan. The file name 
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PRIMARY 
MISSION 


EVENT 
atts [son] cane [Goanfrusnsusn [Love ]AGWS [oor 


VALUES 


CALL1 -- INTEGER 1,2,3,... 

SQN - LETTER A-l ORGANIC X NON-ORGANIC 
CALL2 -- INTEGER 1, 2, 3, 4 

QUANTITY -- INTEGER 1, 2,3,... 

PRIMARY MISSION -- SEE APPENDIX A 
SECONDARY MISSION -- SEE APPENDIX A 
LAUNCH CYCLE -- INTEGER 1, 2,3,... 
RECOVER CYCLE -- INTEGER 1, 2,3,... 

DAY OR NIGHT -- BINARY 0 = DAY, 1 = NIGHT 


Figure 4 Event Entity 








corresponds to a date in the form MMDDYY. The actual date is not important but the 
uniqueness of the date is. The date is the key element for finding an individual airplan 
to analyze or reproduce. Within the AIRPLAN files the key attribute for the EVENT 


entity is the callsign. 


D. DATA OBTAINED 

The data consists of six months of deployment airplans. |The deployment was 
made by Carrier Airwing 11 (CVW-11) embarked in USS Abraham Lincoln (CV-72) to 
the Pacific and Indian Oceans during May through November of 1991. This was 
considered a typical Western Pacific, peace time deployment. While the Persian Gulf 
War was in the recent past, this had little effect on how business was conducted during 
this deployment. 

Approximately 110 airplans were obtained. The 110 airplans vice the 180 days that 
make up six months, is explained by taking into account inport periods. It is not 
uncommon for 30 or 40 percent of a peacetime deployment to be spent in foreign ports. 

Some of the 110 airplans were eliminated, most because they were no-fly days or 
minimum fly days. These airplans, from experience, do not represent normal business 
aboard the carrier. Furthermore, production of these airplans does not pose a great 
problem for Strike Operations. After this, 75 airplans remained. Most structure oriented 
information was taken from the 75 remaining airplans. Detailed analysis was then 


conducted on 34 airplans. 
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iI. AIRPLAN ANALYSIS 


A. APPROACH 

The airplan can be viewed as columns, rows or individual blocks. Each of these 
views is taken in the analysis of the individual airplan files. Each view gives insight into 
a different facet of the airplan and carrier operations in general. If columns are 
considered, the information derived from a number of airplans refers to cycle 
comparisons such as average number of launches per cycle. Squadron launch averages 
can also be obtained along with how these affect the airplan throughout the day. 
Analysis along rows yields information concerning individual squadron operations and 
how they compare. Total number of sorties per squadron, and the day and night sortie 
breakdown, are the primary pieces of information obtained from horizontal analysis of 
the airplan. Individual block analysis of the airplan focuses on mission areas, squadron 
operating procedures and sortie duration. This enables the analyst to compare, on a 
sortie by sortie basis, how different squadrons and/or aircraft types differ in their 
operating procedures. Individual sortie analysis also allows the analyst to characterize 
each airplan with an emphasis on mission area. 

The goals of the analyses were to gain insight into enough facets of the airplan to 
make recommendations on possible ways to improve the production process. In addition 
to insight, it was necessary to ensure that the airplans obtained were a reasonable sample 


of the overall population. The fact that the airplans obtained were actually approved and 
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flown may make the second goal seem trivial, but approval alone is no guarantee that an 


airplan is "good." It would be less than optimal to start out with a group of substandard 


airplans. 


B. ORGANIZATION 

The airplans were obtained in standard hard copy airplan format. After the 
structure was established, approximately one hour was needed to transfer a hard copy 
airplan to a computer format that could be used for analysis. The transformation to a 
working data set was accomplished in Paradox 3.5, the software choice for the database 
portion of this thesis and model development. 

Initially, the data analysis was structure oriented. Total cycles, total sorties and 
day night ratios from the 75 airplans were examined in an attempt to limit unnecessary 
data entry. From this initial examination of the airplans, a cursory definition of a 
standard airplan was made. Table 2 shows the results. It was determined that further 
analysis and subsequent model development should be structured around the standard 
(average) airplan. Table 2 shows the standard airplan to have four day cycles, three 
night cycles and approximately 85 sorties flown throughout the day. 

A group of 34 airplans was organized into individual airplan files. The files are 
constructed of the EVENT entities that make up a daily airplan. From this format, the 
files were merged and sorted for the analysis of each area. The merging of the daily 
airplans took place in Quattro Pro 3.0. Quattro Pro was chosen for its built-in ability 


to communicate with Paradox 3.5, and for its ability to perform complex logical 
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TABLE 2 CYCLE AND SORTIE INFORMATION 


DAY | DAY | SORT/ | NITE | NITE | NSORT/ | TOT 
acee ae ne a ros = CYC 
Fave | 4.33 | 44.24 [14.75 [29 | 40.13 | 13.87 | 


STD 15.01 5.00 0.80 | 12.14 2.04 1.07 16.13 
rice 


[Max | [sf 6 i967 |10 | 40 
(mae kee Se ee Ce ie a 












selections and basic statistical calculations. Using the spreadsheet environment made 


parsing the data easier. 


1. DAILY Files 
As Stated above, a file was made with the contents of each individual daily 
airplan. These files are used in the production application. The information is needed 
from each airplan to form the other analysis files. Data such as number of day and night 
cycles, total sorties, and overall mission percentages are used by the production 
application to characterize an airplan for future use. This information is presented in 


Table 3. Table 4 is a portion of a DAILY file. 


2. OVERALL File 
A file of all recorded events was made by combining the DAILY files. This 


OVERALL file contains all events in the database. The size of the file precluded its use 
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TABLE 3 DATABASE SEARCH FILE 
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DAILY FILE 


TABLE 4 
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for all but the simplest calculations. This file was used to obtain overall airwing 


Statistics. The size of the file and nature of the final use allowed structuring the 
OVERALL file without a DATE field. If the records of the OVERALL file were 
required to be unique, a "DATE" field could easily be added. During analysis of the 
OVERALL file the decision was made to eliminate sorties that did not both launch and 
recover on the carrier. As discussed earlier these type flights, due to their small number, 
along with the helicopter sorties, do not have a proportionally large impact on daily flight 


operations. 


3. SQUADRON Files 

A file was also formed for each squadron. These files are made up of all 
events flown by each squadron. The files were obtained by sorting the OVERALL file 
on the squadron letter attribute. These files have little use to the scheduler on a daily 
basis, but they allow collection of individual squadron statistics over an extended period. 
This information is useful for comparison within the airwing and for comparison with 
published Navy training requirements. The comparison with Navy training and readiness 
requirements helps ensure that each squadron is provided the opportunity to maintain full 
mission capable aircrew. 

Analysis of the squadron files allowed a close look at mission areas flown by 
each squadron. In the case of the F-14 and F/A-18 squadrons, comparisons between 
sister squadrons were made. This mission data was important when designing the 


interface with the database of previously flown airplans, because the published 
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requirements for mission readiness in each mission area can be used as scheduling 


guidelines. 


C. TECHNIQUES USED 

In each of the files, it was necessary to use logical comparisons to gather 
information from the data. The logical functions of Quattro Pro proved invaluable in this 
process. The statistical functions of the Quattro Pro spreadsheet package also proved 
useful. Appendix B contains the functions and macros used in the analysis. Numerous 
samplings were taken from the data. The analysis was approached by extracting as much 
information as possible from each file according to the file type. The results are 


discussed in a similar fashion. 


1. DAILY files 
Statistics were collected on the DAILY files with the goal of characterizing 

a typical daily airplan. This characterization was needed for two reasons. The first 
reason is for comparison with the combined data, or the OVERALL file. The second 
use is in distinguishing airplans in a way that would be helpful during airplan production. 
This characterization is accomplished using the parameters with which the ASTKE 
structures each day’s airplan. These parameters are: 

©@ Number of day cycles 

@ Number of night cycles, 


@ Number of total sorties. 


© Time flight operations will commence. 





The time will not be part of the analysis but it is accommodated by the prototype model. 

The reason for this is the that the hour when flight operations commence or terminate 
is not as important as the number of day and night cycles. In addition to the above listed 
parameters, three others were examined, night sorties, squadron totals and mission 
influences. Night sortie importance to maintain pilot night currency was discussed 
earlier. Mission influences further differentiate one airplan from another. Squadron total 
sortie information for comparison with training requirements. 

It was thought that the distribution of sorties among squadrons would be a 
good descriptor of the airplan. After initial analysis, however, it was discovered it is 
not. This measure proved fairly constant. Table 5 shows these results. These results 
also match, with reasonable tolerance, the expected distribution from Reference 3. The 
close match between the equitable distribution and the actual distribution tends to validate 
the acceptability of the airplans used. 

The numbers and types of cycles and sorties are additional input data. The 
analysis consisted of gathering the totals from the daily airplans and calculating the 
necessary statistics. The mission data, however, was not straight-forward. The mission 
data was extracted via logical comparisons in all stages of the analysis. At this stage, 
the mission data was extracted to help describe a certain airplan. The logical comparisons 
used to extract mission data can be found in Appendix B. This information is helpful 


in picking an airplan from the database for production. 
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TABLE 5 AIRWING SORTIE DISTRIBUTION 


{ 


4.32 
9.29 
2.15 
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2. OVERALL File 
Once all the daily files were combined, the total number of events was 2176. 
The total number of sorties flown from these events was 3258. This yields an average 
of 1.49 sorties per event. The standard deviation on this average was 0.58 sorties. This 
information shows that the airwing, overall, launches with either one or two aircraft 
most of the time. This fact helped determine the use of the EVENT entity as the basic 
entity of the database for the analysis and prototype production model. 

An interesting piece of information from the overall file was the day to night 
sortie ratio. Of the 3258 sorties entered into the database, 1619 recovered at night. This 
high percentage of night sorties, 49.7 percent, shows the attempt being made to maintain 
pilot night currency and the ability of the airwing to operate at night. "Was the high 
percentage of night sorties planned or did tasking work out to provide sufficient day to 
night ratio?" A discussion with the Assistant Strike Operations Officer on the Abraham 
Lincoln answered this question. The policy used during this period of operations was 
to schedule the airplan as tasked without regard for night landings. If airwing pilot night 
currency began to suffer, only then was emphasis placed on maximizing the number of 
night sorties within the constraints applied by AIROPS. Some of the costs associated 
with flying too many night sorties are often overlooked. Night flight operations are not 
only significantly more dangerous than day operations they also are less productive. 
Time is wasted in the holding pattern or Marshall stack. This flight time could be use 
more efficiently. Time spent in the Marshall stack by night sorties could have been used 


for secondary mission area completion. When the airplan can be analyzed, along with 


29 








other related statistics such as percent pilots night current, this area will be more useful. 
The data needed for this analysis is not available now. 

The OVERALL file produced the airwing’s average sorties per event, average 
number of cycles flown per event and the associated deviations for each. These allow 
the analyst to estimate the number of flight hours flown by the airwing for each airplan 
in the database. This also allows an estimate of the number of events that normally 
launch in any cycle. Given the constraints placed on the airplan by Air Operations of 
approximately 15 sorties per night recovery, one can estimate the number of events 
allowed to launch during any given cycle. 

The fina) area of interest in the OVERALL file was the mission data. This 
information was extracted from the file through a series of logical comparisons. The 
mission portion of the airplan can be broken down into three areas, primary, secondary 
and tertiary. Every event has a primary mission. While every aircraft is capable of 
accomplishing multiple missions on a single sortie, the assignment of secondary and 
tertiary missions depends several factors. Analysis showed the number of secondary and 
tertiary missions was relatively small compared to the number of aircraft that are multi- 
mission. Only 863 of 3258 sorties or 26.5 percent had official secondary missions and 
63 or 2.6 percent had tertiary missions. The decision was made to discard tertiary 
missions as a Critical factor in the analysis and production phase of the airplan. The 
model has capability to accommodate tertiary missions, but the analysis will not include 


them. 
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Table 6 shows the overall mission breakdown for the airwing. Appendix A 
contains short a explanation of each mission area. The primary and secondary missions 
were given the same weight in the analysis; no added weight is given to either mission 
based on its relative position on the airplan. This is strictly a count of actual times a 
mission occurred on the airplan. 

A byproduct of the mission data analysis is the number of mission areas 
needed to cover the airwing’s tasking and training. Twenty-three mission areas account 
for approximately 94 percent of airwing flights. These numbers will be compared with 


squadron mission statistics in the next section. 


3. SQUADRON Files 

The SQUADRON files gave valuable insight into sortie and mission 
distributions. These files lend credence to each specific airplan’s validity. As seen in 
Table 5, the comparison between sister squadrons was within one half of a percent in 
both cases. The distribution of sorties throughout the airwing comes close to the mix 
required to maintain aircrew qualifications. Table 7 shows total sortie numbers by 
squadron. Again, the comparison made between sister squadrons tends to validate the 
airplans used. 

SQUADRON files provided another chance to analyze mission data. A 
similar technique to gathering mission data was applied to each of the SQUADRON files. 


Table 8 shows the distribution of each mission area over the airwing. 
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TABLE 7 SQUADRON SORTIE STATISTICS 


AVG. : 
TOTAL | NIGHT AIC STD 
SQDN | SORTIES | SORTIES PER DEV 
EVENT 


Ce se 
1.03 
{0.634 





While some of the mission areas are aircraft specific, such as anti-air warfare missions 
like AIC, ACM and CAP, the information in Table 8 shows how the shared missions 
are divided among those capable of doing them. The percentages in Table 8 are, again, 
totals of sorties that had a given mission assigned with no weight given to whether the 
mission was assigned as a primary or secondary mission. This explains why neither the 
columns nor rows sum to 100. The numbers should only be used for comparison within 
the airwing. The OTH column accounts for unique mission assignments, a conglomerate 


of rarely flown missions. 
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Some interesting information is available in Table 8. Mainly, the distribution 


of certain primary mission areas within the airwing. The distribution of tanking sorties 
is an interesting example. There are only two aircraft that can provide organic airborne 
tanking to the rest of the airwing, the A-6E and S-3A. Approximately 37 percent of 
A-6E sorties were tasked with either the mission tank (MTNK) or recovery tank (TNK) 
mission compared to over 65 percent of S-3A sorties. When more data is available 
through saving airplans in an easily analyzed format, the ship and airwing will have a 
way to compare shared missions to ensure an equitable distribution. 

The information that proved valuable for the model choice from both Tables 
5 and 7 was the large number of possible mission combinations. Narrowing the number 
of mission areas to 23 left an average of only seven percent of each squadron’s total 
sorties unaccounted for. This led to the conclusion that mission data is much too fluid 
to account for fully in a prototype model. 

Some of the information from Table 8 may be confusing to the reader 
unfamiliar with carrier and airwing operations. One such area is the high percentage of 
E-2C (VAW) sorties scheduled for Touch and Goes (TG/T). This is common among 
most airwings. The E-2C is a dual piloted aircraft. To maintain night currency, it is 
common for one pilot to fly a touch and go and the other pilot fly the final landing. 
When night sorties are scarce, this technique is used by the airwing to boost VAW pilot 
night currency. Another point brought out by Table 8 is seen in the Tactical Air 
Reconnaissance Pod (TARPS) mission column. It is common for only one VF (F-14A) 


squadron to fly all TARPS missions. This is due to the aircrew training required for the 
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TARPS mission and the cost of the TARPS pods. The extra TARPS sorties flown by 


VF-2 were partially compensated for in the AIC mission area. VF-1 flew approximately 


10 percent more AIC missions than VF-2. 


D. RESULTS SUMMARY 

The airplans obtained proved to be good candidates for future use. The distribution 
of sorties and missions follows the necessary requirements for readiness as prescribed in 
the joint AIRPAC/AIRLANT Training and Readiness Instruction. The analysis of the 
breakdown of day and night sorties throughout the airwing showed these airplans provide 
an equitable mixture and a chance for each squadron to maintain a maximum number of 
night current pilots, without flying an unnecessarily high number of total sorties at night. 
The airplans analyzed had approximately 50 percent of the sorties flown recovering at 
night. While this might seem a little higher than required, it is not unreasonable. The 
sortie per cycle rate was found to be 15 during the day and 14 at night which confirms 
known limitations applied by AIROPS. Deviations in number of cycles, sorties and 
sorties per cycle were found to be small. 

Mission data showed a relatively small percentage of sorties being launched with 
secondary and tertiary missions, 25 percent and 3 percent respectively. Mission analysis 
also confirmed standard operations in numerous areas such as; TARPS, Touch and 
Goes, and Airborne Tanking. Approximately 95 percent of sorties flown from the 


carrier can be accounted for using 23 missions. This number is reduced when 
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considering only a single aircraft type but the number of mission combinations is still 


quite large. This fact will affect the feasibility of different prototype models. 
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IV. MODEL RECOMMENDATIONS 


A. POSSIBLE SOLUTIONS 

Several common operations research techniques, each with its strengths and 
weaknesses, exist for solving scheduling oriented problems. One of the most useful 
techniques is mathematical programming. Two possible mathematical programming 


approaches will be discussed. 


1. Expected-Value Coefficient Linear Program 

A linear/integer program could be used to solve the problem of the airplan 
production. In this case, the averages for total sortie and mission area breakdowns 
gathered in Chapter III would be used as constraint coefficients for a linear program. 
The division of total sorties and day/night mixture within each squadron could be treated 
as constant over a long period of time (a deployment, for example). This method would, 
given proper formulation, provide an optimal mixture of sorties over an average number 
of cycles. The basic template could then be modified by Strike Operations to meet the 


actual tasking for the next day. 


2. Interactive Linear Program 
The analysis from the Chapter III also suggests an interactive linear program 
or optimization model. Unlike the expected value model, this would take, as input, the 


known data for the next day’s airplan. That information could include: 
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@ Number of day cycles. 


© Total number of sorties allowed. 

@ Number of up (flyable) aircraft for each squadron. 
@ Mission priorities. 

@ Division of sorties within the airwing. 


@ A small amount of historical data. 


_An interactive program could then formulate a unique linear program each day. A model 
of this type would be very dynamic. An airplan could be formulated almost to 
completion. 

3. Discussion of Mathematical Programming Approaches 

These two approaches were seriously considered for the prototype model. 
A major portion of the analysis was directed towards designing an adaptation of the 
linear program found in Reference 4 which could be adapted to either approach. The 
interactive linear program was chosen initially. It was quickly determined that the 
amount of interaction adversely impacted the size and complexity of the problem. The 
linear program quickly grew very large. Initially, this did not seem to warrant 
discarding the idea. Eventually, however, as the results approached realistic conditions, 
the problem formulation grew to a size that was unmanageable for the expected 
computing power of the intended user. Thus, the rejection of the interactive linear 


program solution. 
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The interactive linear program problem violates two of the requirements 
discussed in Chapter I. The amount of interaction required, found to be considerable to 
make the linear program realistic, violates the simplicity requirement, making it difficult 
for the program to be introduced and used in the fleet. The sheer size of the problem 
violated the cost constraint. The optimization package in Quattro Pro was unable to 
handle either of the above discussed linear programs. A commercial add-on program that 
works within Quattro Pro was investigated but the version required to handle even a 
moderate-sized airplan cost $1000 per copy. 

The expected value model would provide only one airplan template for use 
by Strike Operations unless there existed several different linear programs to handle a 
limited mixture of total sorties and number of cycles allowed. This would require a 
different formulation for each template. The large number of possible missions and 
mission combinations preclude this approach. As discussed in Chapter III, 94 percent 
of the missions are accounted for with 23 mission areas. The possible combinations 
quickly increase the size and complexity of a linear program. 

While neither of the optimization programs solved the problem, they were 
helpful in gaining insight into the carrier airplan. The interactive linear program in 
particular could be a valuable tool for in-depth airplan analysis. 

4. Iteration Method 

A computer program could be written to generate all possible airplans for a 

given number of cycles and sorties. This brute force approach would produce a very 


large number of possible airplans. The initial number of airplans could be reduced by 
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placing some reasonable constraints on the generation program. The output from the 


initial program could then be run through a number of culling sub-programs which would 
sort through and pare down the list until a reasonable number of candidate airplans 
remained. This method is an excellent project for a Computer Science thesis but is 


rejected here for size and complexity reasons. 


B. INTERACTIVE DATABASE SEARCH MODEL 
A approach found to best meet the simplicity and cost requirements, while 
achieving the established goal, to assist ASTKE by reducing the repetitive work he must 
currently accomplish, proved to be an interactive database search model. The basic 
procedure for this model is: 
@ Characterize the airplan in a concise way that benefits the production process. 


@ Place the characterizations into a database that can be searched and sorted quickly 
and easily. 


@ Provide ability to retrieve a sample of a few airplans from what would be a larger 
more cumbersome database. 


@ Provide a means to make minor changes to the chosen airplan template and save 
it for future incorporation into the database. 


1. Assumption 
As discussed in Chapter II, several previously flown airplans were entered 
into the database supported by both Paradox 3.5 and Quattro Pro 3.0. Constraints, such 
as number of sorties per cycle, amount of airborne fuel available, and the concern over 
equitable division of available sorties, are assumed to be at least partially accounted for 


if the proposed airplan for the next day is based on an airplan that has already undergone 
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the scrutiny necessary for approval. The analysis backed this assumption. The airplans 


used for the initial database were composed using an equitable spread of sorties. 


_2. Model Basics 

A basic description of the chosen model follows. A more user-oriented 
version can be found in Appendix C. The idea behind the database search model is that 
Strike Operations be given an initial database which includes several “standard” fly days 
for an aircraft carrier. Through the process of updating of the database and the search 
file, the database is eventually tailored to the way the individual ship and airwing do 
business. After a few months of flying the original database could be purged, leaving 
only that ship’s airplans present. 

The general flow through the model is accomplished first in Paradox where 
the user selects a candidate airplan via menu driven queries. The date associated with 
that candidate airplan is the file name for that airplan in Quattro Pro. The spreadsheet 
file or files are then viewed in Quattro Pro. Once the best airplan is chosen it can be 


altered to meet specific tasking. Each stage of the application will be discussed. 


3. Paradox 3.5 
The Paradox portion of the application is menu driven queries that prompt 
the user to select an airplan based on a number of different criteria. Figure 6 is a 
diagram of the menus. The menus were constructed using Paradox’s Personal 
Programmer Feature, which allows database queries to be saved as menus. The queries 
defined by the interactive menu selection and user inputs ensure selection of the airplan 


which best meet the tasking for the next day. 
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The choices for airplan selection are made by querying the inputs commonly made at the 
beginning of airplan construction. The six query choices are: 

@ Number of day cycles and night cycles. 

® Number of total cycles. 


@ Number of total sorties. 


Number of night sorties. 


Number of total cycles and total sorties. 


Day cycles, night cycles and total sorties. 


Each of the queries above returns a table of airplans that meet the desired inputs. 
Additional information characterizing the airplans is available in the resulting query 
answer table. Along with the date corresponding to the airplans are a number of mission 
area percentages. These percentages reflect the number of sorties on that airplan that 
have that mission as a primary or secondary mission. This further distinction gives the 
scheduler another method of narrowing the possibilities. 

If queries are unsuccessful or it is determined by ASTKE that flight 
operations for the next day will be very specific, a number of blank templates are 
available for constructing an airplan from scratch. These will be discussed in the next 
section. The result from Paradox is simply a date or number of dates corresponding to 
Quattro Pro file names. The user uses these dates to choose a template for the next day’s 


airplan. 
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4. Quattro Pro 

The portion of the application designed in Quattro Pro consists of two file 
types modifiable to meet the needs of the ASTKE. Both are airplan templates, one is a 
previously flown airplan, the other is a blank airplan template. The end result is the 

same, an airplan that can be published directly from the computer. 
A series of macros and spreadsheet functions help ASTKE with the more 
tedious tasks. The macros and functions can be seen in Appendix B. They accomplish 
line drawing and computation of sortie totals for each squadron and each cycle. This is 
accomplished by using the ability to name and hide blocks in the spreadsheet. Where 
quantities are involved, named blocks and Quattro Pro functions are used to calculate the 
appropriate values. Figure 6 depicts the layout of named blocks and hidden columns 
used in calculations. The blocks are summed vertically and horizontally to receive cycle 
launch and recover totals, squadron day and night sortie totals, and, overall total day and 
night sortie totals. Presently this is done by hand and must be done each time a change 
is made to the airplan. Since the total number of sorties is usually an externally imposed 
constraint, an updated total relieves ASTKE of the need to consistently recalculate sortie 


and cycle totals. 


C. CONCLUSIONS 
While the interactive database model meets the goals and requirements outlined in 
Chapter I, it has some limitations namely limits of the macro language and difficulty in 


data extraction. They are lessened with spreadsheet experience, but not easily. 
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Figure 6 Quattro Pro Block Structure 
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The goal is to provide a model to ASTKE for evaluation. It is accomplished. The 
prototype model can be experimented with at little cost to the user. If the concept is 
accepted, a final model can be constructed using lessons learned from the prototype. 
Once the prototype is in use, an extensive database of airplans will be available for 


further analysis. 
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V. CONCLUDING REMARKS 


A. MODEL USE 

The interactive database model described in Chapter IV will be provided to the 
Assistant Strike Operations Officer of the USS Abraham Lincoln for use during an 
upcoming work-up and deployment cycle. The results will determine whether further 
development of this approach is warranted, or if prototype development of one of the 
other models discussed should be investigated. — 

Undoubtedly, the model will relieve the Assistant Strike Operations Officer of some 
repetitive tasks. This alone does not warrant development of a final model. There could 
be other problems introduced. After the trial period, the Strike Operations team should 


be able to provide valuable inputs to a final model. 


B. PROTOTYPE REFINEMENTS 

One refinement to be accomplished during fleet introduction will be a Quattro Pro 
macro to assist ASTKE in drafting the Air Tasking Order (ATO) that is promulgated to 
the warfare commanders. This macro will also enable ASTKE to form the DAILY files 
necessary to update the database search file. This macro is a mirror image of the macro 
used to build the airplan templates. This will not be done, however, until the model is 


more thoroughly tested. 
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C. FURTHER RESEARCH PROJECTS 


If it is determined that the database approach satisfies the needs of Strike 
Operations, the final model should be a stand-alone program designed specifically for the 
task of writing the airplan. The prototype model described in Chapter IV is limited by 
the software chosen. The spreadsheet environment is adequate for testing the idea but 
a program written with the single goal of airplan production would be much better. A 
student in the Computer Science Department should be sought to accomplish this for 
thesis work. 

In addition to a stand-alone airplan production program, another thesis project is 
possible. A more intricate database structure could be developed to work along with the 
final model, extracting significant data. Once again, the choice of software present limits 
the data collection. Data is not easily extracted. A substantial amount of spreadsheet 
knowledge is needed to extract the data from the airplan files. Macros can be written to 
accomplish the data extraction but the macro language of Quattro Pro is not as flexible 
as a structured programming language. The database structure would be an excellent 
project for a thesis student in the Information Systems curriculum. If students from both 
the Computer Science and Information Systems curricula could be encouraged to work 


together, the final product would be valuable to a number of Navy commands. 


D. RECOMMENDATIONS 
From numerous conversations with former and current Strike Operations and 


Assistant Strike Operations Officers, it is apparent that a major portion of the airplan 
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production problem is not its actual construction. Often, it is the interactions throughout 
the ship, airwing and battlegroup that force the airplan to be published at late hours. . 
Examples of such factors are changes in forecasted weather or an unforeseen loss of ‘ 
assets ( aircraft down for maintenance ). These interactions must be dealt with 
individually and prioritized. In most cases, their impact can be minimized or eliminated. 
For any automation process to have a noticeable impact on the publish time of the 
airplan, the process itself must be revised io some extent. 
Throughout the day, numerous inputs are made that force changes to the next day’s 
flight operations. The changes come from many areas as discussed in Chapter I. The 
impact of the changes can vary from minor mission changes to major restructuring of 
flight operations for the next day. The major changes are for the most part 
uncontrollable. They usually reflect a change in battlegroup tasking either by the 
battlegroup commander or fleet commander. Revised tasking can be promulgated at any 
time and is generally accepted as the nature of the business. These problems must be 
addressed at a level much higher than will be impacted by this thesis. 
The changes that can be controlled are the ones that reflect operations internal to 
the battlegroup, mainly, combined warfare commanders and individual squadron’s needs 
or wants. Many of these changes can be minimized by establishing guidelines for 


changes to the airplan: i.e. who can make these changes and when. 


1. Airwing Planning Session 


It is recommended that squadron representatives meet with ASTKE or the 4 


Airwing Operations Officer in a short planning session for the next day’s events after 





warfare commander tasking has been received. A meaningful planning session would 
force squadron inputs to be made early in the day. Once the tasking requirements are 
met, secondary missions could be added to allow squadrons to accomplish necessary 
training. The analysis showed only 27 percent of the sorties launched were multi-mission 
sorties. While some missions require a complete sortie to accomplish, many can be 
accomplished as secondary missions without interfering noticeably with the primary 


mission. 


2. Limit Change Opportunities 

Another recommendation is to set a deadline when all routine airwing airplan 
changes must be made. The intent is to force squadron operations officers to make their 
changes earlier in the day and to reduce the number of unnecessary changes. 

Limiting the ability to make changes to the airplan throughout the day could 
be detrimental to the quality of the final product. If legitimate changes are suppressed 
for the sake of publishing the airplan at an earlier time, the airplan will not reflect what 
will actually happen. The changes will be made during execution and what is actually 
flown will not reflect what was scheduled. If the recommendations stated earlier are 


implemented, this problem must be watched for and handled carefully. 
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APPENDIX A - LIST OF MISSION AREA ACRONYMS 


ACM Air Combat Maneuvers. 

AEW Airborne Early Warning. 

AIC Air Intercept Control. 

ASW Anti Submarine Warfare. 

BMB Bombing. 

CAP Combat Air Patrol. 

CQ Carrier Qualification. 

DACT/M_ Dissimilar Air Combat Maneuvers/Training. 

ESM Electronic Support Measures. 

EX Exercise (Any Type). 

FCF Functional Check Flight, Post Maintenance Checkflight. 
LWLVL Low Level Navigation. 

MAS Maritime Air Superiority (Long Range CAP). 

MTNK Mission Tanker. 

NAV Navigation. 

NVG Night Vision Goggles. 

SSC Surface Search and Communication. 

TG/T Touch and Go then Trap. . 


TARPS Tactical Air Reconnaissance Pod. 
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@ TNK Recovery Tanker. 


@ SVCS Services Provided to Another Asset. 
@ STK Strike (actual or simulated). 
@ YOYO Launch and Recover on Same Cycle. 


@ OTH Other. 
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APPENDIX B - ANALYSIS TOOLS 


















A. QUATTRO PRO 3.0 ANALYSIS TOOLS 

Numerous "@" functions and macros were used to extract data from each of the 
file types discussed in Chapter II. For those unfamiliar with the spreadsheet 
environment "@" functions are mathematical or logical functions that are applied to a cell 
or block of cells in a spreadsheet. Macros are small programs written in a language 
specific to the software applications in use. Macros call menu selections or "@" 
functions when they are activated. Quattro Pro macros are activated by naming a macro 
in one of a number of ways. Ali macros used in the analysis were named using the 
\"letter" option in Quattro Pro. The macros are then activated by depressing the ALT 
key and the letter name simultaneously. Some of the macros and "@" functions used in 


the analysis are listed below for further use. [Ref 6] 








1. Mission Selection 






This function was used to extract the number of each mission type for 





individual sorties. It compares the primary and secondary mission columns with a 







column header it returns a 1 if there is a match, a 0 if not. 


@IF (@EXACT($E2,K$1),1,@IF(@ISSTRING($F2),@EXACT($F2,K$1),0)) 








The next function was used to gather information concerning squadron 
Statistics from the OVERALL file. It compares the column header with the squadron 


letter cell. It returns a 1 if there is a match, a 0 if not. 


@IF ( @EXACT($E2,K$1),1,0) 


The inner product or dot product function (@SUMPRODUCT(’COL1’,’COL2’) can be 
used on the resulting column of ones and zeros with other columns yielding the number 
of sorties with a given trait, such as: 

@ launch or recover cycle. 

© number of cycles flown. 


@ number of aircraft per event. 


2. DAILY File Modification Macro 
The following macro was used to restructure the daily airplan files. The 


structure of these files, as originally entered into the database was not readily transferable 


to airplan format. 


{HOME} 

{/ Column;Insert}A1..J1~ 

{HOME}{RIGHT 1}{;CATENATES CALLSIGN COMPONENTS} 
@STRING(K1,0)&L1&@STRING(M1,0) ~ 

{/ BLOCK;COPY}B1 ~ 

B2..B150~ 

{HOME} {RIGHT 1} 

{/ Block; Values}B1..B150~ 

B1..B150~ 
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{; JOINS MULTIPLE MISSIONS TO ONE FIELD} 
{HOME}{RIGHT 5}{;MOVE TO CELL F1} 
@IF((@ISSTRING(O1)¥AND#@ISSTRING(P1)),(O1&" ,"&P1),01) ~ 
{/ Block;Copy}F1 ~ {;COPIES JOINED MISSIONS TO APPROPRIATE 
CELL} 

{;MOVES INFORMATION TO APPROPRIATE PLACES} 
F1..F150~ 

{HOME}{RIGHT 5} ~ 

{/ BLOCK; VALUES}F1..F150~ 

F1..F150~ 

{HOME} 

{/ BLOCK;MOVE}NI1..N150~ 

D1..D150~ 

{/ BLOCK;MOVE}Q1..Q150~ 

11..1150~ 

{/ BLOCK;MOVE}R1..R150~ 

31..150~ 


~ 


3. Event Transfer Macro 
This macro was used in transferring the events from the DAILY files to the 
airplan templates. A slight modification to this macro would enable copying airplan 
information from airplan to DAILY file format. 
{/ Block;Copy}{;COPY BLOCKS TO AIRPLAN TEMPLATE (\C)} 


{RIGHT 7} ~ 
{NEXTWIN} {DOWN 6}{2} 


4. Statistics Gathering 
The following macro creates columns for gathering information on 
squadron operations. It is formatted for usc on DAILY files. 
{HOME} 
{/ Row;Insert} ~ 
{HOME} 


{RIGHT 20} 
A{RIGHT} 
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B{RIGHT} 
C{RIGHT} 
D{RIGHT}{;FORMS COLUMNS FOR EACH SQN} 
E{RIGHT} 


@EXACT(U$1,$L2) ~ 
{/ Block;Copy} ~ 
U2 


{2}~ 

{2}{;USER INTERACTION} 
A 

{RIGHT}B 

{RIGHT}C 

{RIGHT}D 
{RIGHT}E{;COPIES COLUMN HEADERS AT BOTTOM OF FILE} 
{RIGHT}F 

{RIGHT}G 

{RIGHT}H 

{LEFT 7} 


~ 


B. QUATTRO PRO AIRPLAN PRODUCTION TOOLS 
1. Recovery Column Reveal and Hide Macros 
The following macros are used to reveal and hide the columns used in 
calculating 12coveries for each cycle. 
{/ Column;Hide} ~ {right 7} ~ {; HIDE RECOVERY COLUMN (\H)} 


{/ Column;Display} {right} ~ {right 8} ~ {; REVEAL RECOVERY 
COLUMN (\R)} 


~ 
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2. Line Drawing Macros 
The following three macros were written to aide ASTKE in altering the 
airplan templates for specific tasking or if an airplan is being composed from scratch. 
These macros not only draw the appropriate lines for single, double and triple cycle 
sorties they also place the appropriate number of sorties recovering in each 


recovery column. 


-~ {right 2} ~ {;SUBROUTINE CALLED BY LINE DRAWS} 


{FOR C4,1,4,1,A2} ~ {;SINGLE CYCLE LINE DRAW (ALT S)} 
{LEFT 5}{/ BLOCK;COPY} ~ 
{RIGHT 4} ~ 


~ 


{;DOUBLE CYCLE LINE DRAW (ALT D)} 
{FOR D11,1,4,1,A2} ~ 


{FOR D12,1,7,1,A18} ~ 
{LEFT 8}0~ 

{LEFT 4}{/ BLOCK;COPY}~ 
{RIGHT 12}~ 


road 


\-~ {RIGHT} ~ {;SUBROUTINE CALLED BY MULTI-CYCLE 
DRAWS} 

{(; TRIPLE CYCLE LINE DRAW (ALT T)} 

{FOR D21,1,4,1,A2} ~ 

{FOR D22,1,7,1,A18} ~ 

{FOR D23,1,8,1,A18} ~ 

{LEFT 8}0~ 

{LEFT 8}0~ 

{LEFT 4}{/ BLOCK;COPY} ~ 

{RIGHT 20} ~ 


~ 





APPENDIX C - USER GUIDE 
A. INTRODUCTION 

The following is designed to give the prospective user the background needed to 
utilize the interactive database model described in Chapter IV. Each facet of the model 
will be addressed. This appendix along with Appendix B of macros and functions should 
be enough to explain the workings of the application for basic use. 

The application uses two commercially available software programs Paradox 3.5 
and Quattro Pro version 3.0 or higher. All program specific menu commands in this 
document will be Quattro Pro commands. Menu commands and file names will be made 
in all capital letters, such as FILE/SAVE and MACRO1.WQ1. Macro commands will 
be preceded by ALT then the letter corresponding to the named macro, such as ALT A. 
This is how macros are activated in Quattro Pro. If another spreadsheet program is 
being used, the commands will be different. [Ref 5] 

The general flow through the application is accomplished first in Paradox where 
the user selects a candidate airplan via menu driven queries. The date associated with 
that candidate airplan is the file name for that airplan in Quattro Pro. The spreadsheet 
file or files are then viewed in Quattro Pro. 

Once a decision is made on which of the templates is to be used that template 
should be copied with a new file name that corresponds to the date of the new airplan. 
This is accomplished by using the macro ALT Z. It is important to copy the airplan 


prior to making any changes. This keeps the initial database constant until it can be 
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updated. If changes are made to the template airplans the database queries will provide 


erroneous information. Each aspect of the application will be addressed separately. 


B. Paradox 3.5 

The Paradox portion of the application is menu driven queries which allow the user 
to select an airplan based on a number of different criteria. The menus are structured 
to walk the user through the selection process. A diagram of the menus can be seen in 
Figure 5. The menus were constructed using Paradox’s Personal Programmer Feature. 


The user should enter Paradox via the PPROG directory [Ref 7]. 


1. Queries 
The queries defined by the interactive menu selection and user inputs allow 

the user to select an airplan that best meets the expected tasking for the next day. 
Choices are determined by the inputs commonly made at the beginning of airplan 
construction. The six query choices are structured as follows: 

@ Number of day cycles and night cycles. 

@ Number of total cycles. 

® Number of total sorties. 

@ Number of night sorties. 

@ Number of total cycles and total sorties. 


@ Day cycles, night cycles and total sorties. 
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Each of the queries returns a table of airplans that meet the desired inputs. Also note, 
where sorties are involved the constraints are maximums but in determining the number 
of cycles the numbers must be exact matches. 
2. Mission Distinction 

Along with the date for each of the airplans are a number of mission area 
percentages. These percentages reflect the number of sorties on that airplan that have 
that mission as a primary or secondary mission. This gives the scheduler another method 
of narrowing the possibilities. Once a candidate airplan has been chosen, it can be found 


in Quattro Pro spreadsheet format with file name MMDDYY.WQ1. 


C. Quattro Pro 


1. Macro File 
The airplan files the scheduler will be using are saved as Quattro Pro 
worksheets. Upon entering the Quattro Pro environment the MACRO.WQ]1 file should 
be opened. This file contains the macros used to aid the production process. The 
MACRO.WQ1 file is a Quattro Pro macro library. When a macro is activated Quattro 
Pro first looks in that spreadsheet for the commands. If they are not present there, 
Quattro Pro looks for an open macro library. If this file is not open the macros will not 


run. [Ref 6] 


2. Daily Airplan File 
The file names for the airplan worksheets are of the form MMDDYY.WQ]1. 


As suggested earlier the original airplan files should not be altered. Neither should the 
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blank templates. The file should be opened and viewed to see if the airplan meets the 
necessary requirements for the next day. Once an airplan template is selected the ALT 
Z macro should be used. Once again, this is to maintain integrity of the database 


queries. Once this is done, the file has a new name and can then be altered. 


3. Hidden Columns 

Prior to changing the airplan, there are a number of hidden columns that need 
to be revealed. This is accomplished by positioning the cell pointer on the left side of 
the first cycle vertical line, as seen in Figure 6. From this position use the macro 
command ALT R (REVEAL) repeatedly until all hidden columns in the airplan have been 
revealed. The hidden columns contain an H in the cycle row to remind the user they 
need to be hidden when the airplan is complete. The columns are hidden by placing the 
cell pointer in the first column to be hidden and using the ALT H (HIDE) macro 
repeatedly until all recovery columns are hidden. The hidden columns contain the 
number of aircraft recovering in a particular cycle, hiding them is strictly for aesthetics. 
Placing the number of aircraft recovering in these columns allows the spreadsheet 


program to calculate the sortie totals at the bottom of the airplan. 


4. Modification 
With the recovery columns revealed, the airplan can be altered to suit the 
next day’s tasking. It is imperative, for calculation purposes, that the number of sorties 
launching and recovering be placed in the correct column. This is easily determined 
since all columns in the airplan templates are defaulted to contain labels except the 


quantity and recovery columns. Whether a column is considered a label or not can be 
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seen in the input line at the top of the spreadsheet. The word Label will be the first 
word in the input line in all columns except those used in calculations. The sortie counts 
are made by using a series of named blocks. The general layout of these blocks is given 
in Figure 6. Launch and recovery totals are calculated by summing over the named 
blocks. If letters appear in these blocks an ERR message will appear where the total 


shouid be. 


5. Sortie Lines 
If an airplan is begun from one of the provided blank templates, or major 
revisions are made to an existing airplan, there are three other macros designed to speed 
up the process. ALT S, ALT D, and ALT T are line drawing macros in MACRO.WQI1 
for single, double and triple cycle sorties respectively. They are utilized by placing the 
cell pointer in the column preceding the callsign and activating the appropriate macro for 
the duration of the sortie. The lines are drawn for the correct duration and the number 


present in the quantity column is placed in the appropriate recovery column. 
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